fix(desktop): show tray icon on linux sessions without xembed tray - #1563
Open
sannidhyaroy wants to merge 1 commit into
Open
fix(desktop): show tray icon on linux sessions without xembed tray#1563sannidhyaroy wants to merge 1 commit into
sannidhyaroy wants to merge 1 commit into
Conversation
`isTraySupported` reports whether the legacy XEmbed system tray is available, but our tray icon is a `StatusNotifierItem` published on the session bus. The XEmbed tray is missing on sessions that implement only the modern protocol, as well as inside the Flatpak sandbox, so the tray icon and the close to tray option were silently disabled there even though both of them work. The Flatpak build also has to own the well known name that the tray backend requests before it registers the icon with the watcher, otherwise the backend fails with: ``` sni: failed to request bus name 'org.kde.StatusNotifierItem-2-1': No route to host ``` The `--own-name` can be dropped once the backend registers the icon under the unique connection name instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
All contributors have signed the CLA ✍️ ✅ |
Author
|
I have read the CLA Document and I hereby sign the CLA |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
isTraySupportedreports whether the legacy XEmbed system tray is available, but the tray icon is aStatusNotifierItempublished on the session bus. Compose Native Tray's Linux backend speaks SNI over sd-bus and never touches AWT. The XEmbed tray is missing on sessions that implement only the modern protocol, and inside the Flatpak sandbox, so the tray icon and Close to tray were silently disabled there even though both of them work. With Close to tray enabled, closing the window quit the app instead of collapsing it into the tray.Changes
desktopApp/src/jvmMain/kotlin/com/artemchep/keyguard/Main.kt: gate the tray onisTrayAvailable, which reportstrueon Linux and defers toisTraySupportedeverywhere else.desktopApp/flatpak/com.artemchep.keyguard.yml: own the well-known name the tray backend requests before it registers the icon with the watcher.Platform impact
Main.ktis desktop-only, and the Close to tray setting is already gated onPlatform.Desktop.isTraySupportedbranch.Why not probe AWT on Linux
java.awt.SystemTray.isSupported()answers a question about the XEmbed tray, which this app does not use. Measured with the same JDK 21 on GNOME 50 (Wayland, AppIndicator extension):SystemTray.isSupported()XSystemTrayPeer.isAvailable()truetruefalsefalseThe same should apply to any session that ships only an SNI host, such as a Wayland compositor with
waybar, where the icon works but AWT reports no tray. I have not measured that case.Why the Flatpak needs
--own-namelibLinuxTray.socallssd_bus_request_name("org.kde.StatusNotifierItem-<pid>-1")and aborts if that fails. Inside the sandbox, without the name granted:With it granted, the item registers with the watcher and the icon appears. The number is the app's PID inside the sandbox, which is why the name cannot be spelled more generally.
--own-name=org.kde.StatusNotifierItem-*is rejected by Flatpak as an invalid name, and--own-name=org.kde.*tripsfinish-args-own-name-wildcard-org.kdein flatpak-builder-lint.This line can be dropped once the tray backend registers the item under the unique connection name when
RequestNamefails, the way Qt/KNotifications, libayatana-appindicator and Chromium do, which is also why other Flathub apps ship tray icons with only--talk-name=org.kde.StatusNotifierWatcher.Testing
On openSUSE Slowroll, GNOME 50 (Wayland) with the AppIndicator extension:
org.kde.StatusNotifierItem-2-1=ownalongside the existingorg.kde.StatusNotifierWatcher=talk.org.kde.StatusNotifierWatcher.RegisteredStatusNotifierItemsand its menu callbacks reaching the sandboxed process.Refs #1248: the same Close to tray flow on a Flatpak install. The missing bus name ownership is a plausible cause of the icon being unresponsive there, but that report is from KDE Plasma on an older version, and the duplicate instance behaviour it also describes is a separate matter I have not verified, so I have not marked it as closed.
NOTE: Diagnosis, testing and descriptions were done by Claude Opus 5 xhigh. All AI-assisted work has been overseen and reviewed by me.